1. Technical Field
The present invention is directed to a system and method for providing shared web modules. More specifically, the present invention is directed to a system and method for logically merging shared web modules with a primary web module to generate a logically merged web module.
2. Description of Related Art
The programming model associated with Java 2 Enterprise Edition (J2EE) mandates an application packaging structure that consists of an archive, e.g., Enterprise Archive (EAR), that in turn contains one more sub-archives, e.g., web archive (WAR), Enterprise Java Bean (EJB) archive (JAR), Resource Archive (RAR), etc. The EAR file encapsulates all these archives required by the application for executing in the J2EE environment. A WAR file contains the “web” related files (Java, HTML, GIFs, etc.) that are required typically for HTTP clients, e.g., browsers.
It is very often the case that application developers have code and configurations that are identical across multiple WARs, also referred to as web modules. Since this code and configuration is identical in a plurality of web modules, rather than rewriting or copying these common portions of code and configurations into each web module, it would be desirable to be able to share a web module having this code/configuration amongst a plurality of web modules. However, there is no current mechanism for allowing web modules to be shared.
To the contrary, the present mechanisms are limited in that the common code/configuration must be explicitly inserted by the application developer into the web modules. For example, assume that there is a web module that contains 100 JSP files. Now assume that two more web modules are developed that also need to contain these same JSP files. With the present mechanisms, the application developer must copy all of the JSP files into each of the new web modules. This is clearly an inefficient use of storage and, in addition, raises maintenance issues since any future changes to one or more of the JSP files must now be rippled through all of the web modules.
As another example, assume that there are 100 web modules that all have the same security requirements. For example, all of the web modules must be configured with the same User Role. This requires the application developer to perform the same security configuration steps during the web module assembly phase for each web module thereby requiring much human effort and time. In addition, a similar maintenance issue is raised in that, when a change to the User Role is made, this change must be propagated to each of the 100 web modules.
Thus, it would be beneficial to have a mechanism that permits the sharing of web modules by other web modules in a manner that maximizes storage efficiency and reduces maintenance issues with regard to future changes in the shared web modules.